Oracle 12c多租户特性详解：全局用户与本地用户的原理与维护
（题图来自Oracle VP , Sally Piao的摄影佳作，感谢摄影师授权）
编辑手记：这一节我们将介绍多租户架构中用户及权限的变化，全局用户和本地用户，管理方式和内部实现，这篇文章来自<深入解析Oracle>一书的摘录。
前情回顾：Oracle 12c多租户特性详解：从Schema到PDB的变化与隔离
COMMON 和 Local 用户
无论在 CDB 和 Non-CDB 数据库中，用户都拥有一个 Schema，拥有一系列的 Schema 对象，在 CDB 中由于 PDB 的引入，用户范畴有所不同。
在 CDB 模式下，公用用户（Common User）和本地用户（Local User）两个概念被引入进来，公用用户可以在 CDB 和 PDB中同时存在，能够连接 ROOT 和 PDB 进行操作；而本地用户则只在特定的 PDB 中存在，也只能在特定的 PDB 中执行操作；在 PDB 中不能创建公用用户，而在 CDB 中（CDB$ROOT 中）同样不能创建本地用户。
在 CDB 中创建的公用用户要求以 c##或C## 开头，以下测试以常规方式命名的用户将会创建失败，符合规则的用户可以被创建：
当创建公用用户时，Oracle 会向每个 PDB 中同时创建该用户，如果 PDB 未打开，则创建工作会以任务的方式延后。以下查询显示数据库中只在容器1中存在新创建的用户：
此时打开 PDB，则数据库会自动完成之前挂起的内部创建工作：
下图描述了公用用户和本地用户的区别：
在拥有了 CREATE SESSION 权限后，公用用户能够登陆包括 Root 在内的任何 Container。公用用户一般在每个 PDB 中都存在对应的用户信息，在 PDB 中不能存在与公用用户重名的用户，如初始的 SYS 和 SYSTEM 用户都属于公用用户。也只有公用用户能够授权或被授权相应的公用角色和权限。
公用权限是指对所有 Container 都有效的系统或者对象权限，例如一个公用用户被授予了公用权限 CREATE ANY TABLEWITH ADMIN OPTION 可以将这个权限转授给其他公用用户。公用用户之外的权限被称为本地权限（Local Privilege）.
公用角色是指在所有 Container 中都可见的角色，这些角色可能包含全局和本地权限。本地角色只能包含本地权限。授予公用角色的公用权限，对于具有该角色的用户在任何可以连接的 Container 中都将具有该权限。
以下是一些相关的常识性介绍：
一个公用用户在不同 Container 中的 Schema 可以不同；
本地用户只能在各自的 PDB 中进行操作，在不同 PDB 中可以存在同名的本地用户；
PDB 中的本地用户不能登陆其他 PDB 或 ROOT；
PDB 的本地用户只需要在本 PDB 内保持用户名唯一；
本地用户能否访问一个公用 Schema 中的对象取决于其拥有的具体权限；
PDB 能够通过 DB Link 访问其他的 PDB；
在 CDB、PDB 模式下，一个权限在被授权的 Container 中存在。因此，在 PDB 中授予的本地权限和角色和在 Non-CDB 中没有不同，例如，在 PDBHRPDB 中授予本地用户 HR 的 SELECT ANYTABLE 权限，仅在该 PDB 中生效。
相对而言，公用权限和角色可以跨越 Container 生效，当需要跨 Container 进行操作时，需要公用权限或角色，并且这些权限需要在现有和将来创建的 Container 中生效。
在 CDB 中，每个权限或者是在某个 Container 中的本地权限，或者是在所有Container中生效的公用权限。公用权限确保公用用户无需在不同 PDB中重复授权。
类似 CREATE ANYTABLE 的权限，其自身既不是公用权限也不是本地权限，如果一个用户通过 CONTAINER=CURRENT 方式授权，则被授权用户拥有的是本地权限；如果一个权限通过 CONTAINER=ALL 方式授权，则用户获得的是公用权限。因此，一个权限称其为本地或公用权限，完全依赖于其授权方式。
在 CDB 中，每个角色或者是基于 PDB 的本地角色，或者是对全体 PDB 生效的公用角色，所有系统提供的角色（如 DBA）都属于公用角色。
在视图 DBA_USERS 和 CDB_USERS 中都包含了一个字段 COMMON，用于标识公用用户和本地用户。
以下查询显示 SYSTEM 作为公用用户在四个容器中存在：
数据库中存在17个公用用户：
以下查询列出了数据库中的本地用户：
通过指定 CONTAINER 可以限定创建用户的类型，当使用 ALL 选项时，以下命令就创建了一个名为 APPADMIN 的公用用户：
查询 dba_users 视图，可以看到 APPADMIN 的相关用户属性：
注意，在 CDB$ROOT 中不能创建本地用户或角色：
在 PDB 中才可以创建本地用户，以下测试首先连接到 PDB（名称为 ENMO）中，连接用户具备 DBA 权限可以创建用户：
当然在 PDB 中也不允许创建公用用户：
同样在 PDB 中也不能删除公用用户：
以下 SQL 成功在 PDB 下创建了本地用户：
类似的，本地用户不能被授予公用权限或角色，以下尝试在全局授权的命令会返回明确的错误：
在 PDB 内授予本地权限之后，新创建的用户可以登陆本地 PDB 数据库：
下面来研究一下角色。在 CDB_ROLES 视图可以查询 CDB 的角色信息，以下查询可以看到由于 PDB 的引入，角色记录大大增加：
对于 DBA 公用角色来说，在每个 Container 中都存在相应的信息记录：
同用户管理类似，在 CDB$ROOT 中可以建立公用角色，但是不能创建本地角色，公用角色在每个 PDB 中都存在，同样需要以 c## 为前缀开头：
在 PDB 中，同样不能创建公用角色，仅能创建本地角色：
对于系统权限和对象权限，CDB 相应的增加了对应视图用于存储这些信息：
在 CDB 中可以像在 NON-CDB 的数据库中一样进行权限授予与回收：
COMMON 和 Local 用户的内部隔离
在技术实现上，本地用户和公用用户都存储在底层的 USER$ 字典表，该表的结构如下（内容摘录自 $ORACLE_HOME/rdbms/admin/dcore.bsq 文件）：
注意以上结构中的 SPARE1 字段，该字段的注释是“用于 Schema 级别的补充记录”，那么这里补充记录的是什么内容呢？
我们再来查看一下 DBA_USERS 这个视图的内容（摘录内容自$ORACLE_HOME/rdbms/admin/cdenv.sql 文件），其中显示 COMMON 字段内容对应了“decode(bitand(u.spare1,128), 128, 'YES', 'NO')”这一运算结果：
针对在 PDB 中创建的 EYGLE 用户，我们来解析一下 CDB 和 PDB 的用户隔离，由于用户信息是存储在 USER$ 表中，以下查询显示在 PDB 中存在的用户在 CDB 中并不存在，也就是说 PDB 中的用户，仅在 PDB 自己的 SYSTEM 表空间字典表 USER$ 中存在：
首先我们跟踪一下在 PDB 中创建用户的过程：
在跟踪文件目录搜索一下创建用户的语句：
在跟踪文件中记录了创建用户的过程，密码已经被隐藏，摘录主要语句如下，注意 insert 语句将用户信息插入到 USER$ 表中：
如果我们在 CDB 级别创建一个公用用户，那么 Oracle 数据库将如何处理呢？
以下在 CDB 级别进行一次跟踪：
检查跟踪文件，可以发现存在两次 INSERT USER$ 的操作，其中一次是用户进程执行的，另外一次由并行进程执行，也就是将同样的记录插入到 PDB 中：
现在我们再创建一个新的 PDB：
打开两个 PDB：
接下来启用会话和全局的跟踪：
现在可以看到，除了会话进程插入 USER$ 之外，两个并行进程执行了向 PDB 的数据插入，这也就是 CDB 与 PDB 的用户隔离与管理：
搜索 盖国强（Eygle）微信号：eeygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。